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ABSTRACT 

This paper presents the development of an automatic 
programming system for assisting modelers of reliability net- 
works define problems and then automatically generate the 
corresponding code in the target simulation language 6PSS/PC. 

INTRODUCTION 

There has always been a desire of software developers to 
automate more and more of the computer programming process. The 
goal of these developers has been to have a system that can carry 
on a natural language dialogue with the user in defining his 
problem and then to automatically generate the appropriate com- 
puter code. The term automatic programming (AP) has been defined 
as an application of artificial intelligence (AI) in automating 
some aspects of the computer programming process (Barr and 
Feigenbaum 1982). This automation is generally accomplished by 
developing another program, an AP system, that raises the level 
of specifying computer program instructions. In other words, an 
AP system is a program that helps programmers write programs. 

An AP system should improve the overall environment for 
defining and writing the program (Brazier and Shannon 1987). As 
a result of this improved environment, there should be a reduc- 
tion in the amount of detail that the programmer needs to know. 
Quite possibly, the user could even do his own programming with 
the help of an AP system. Also, this improved environment should 
result in a more natural way for the user to define his problem 
that closely resembles the user's way of thinking and looking at 
prob 1 ems . 


RESEARCH GOAL 

The goal of the research presented in this paper is to deve- 
lop an AP system to assist the modeler of reliability networks 
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define problems, and to then automatically generate the program 
code in the target simulation language GPSS/PC. The AP system is 
called Automatic Network Programming System (ANPS). 

The domain of problems that can be solved by ANPS include 
prelaunch activities of space vehicles, operation of ground sup- 
port equipment, space vehicle turn around activities, space 
tr ansportati on systems and operational plans, and hardware 
system with multiple subsystems. The ANPS system requires that 
the problem be defined by: 

° A network of activities with starting and stopping 
events . 

° Activities with either fixed or continuous times. 

0 Activity failures and repairs (mean times to failure and 
repair). 

° Operational dependencies between activities. 

PREVIOUS RESEARCH 

Synder et al . ( 1967 ) developed a simulation model of the 
Saturn V prelaunch activities beginning at T-24 hours and con- 
tinuing through T-0 hours, or lift-off. This model was used to 
predict launch vehicle availability (LVA). LVA was defined as 
the probability of launching the spacecraft within a given launch 
window. A second objective of the model was to identify loca- 
tions in the countdown for placing holds and to determine the 
length of these holds. 

The Synder model consisted of over 1100 vehicle subsystems 
and 400 ground support subsystems. A detailed time line was 
developed showing the interrelationships of these subsystems. In 
addition to the time line, the model input included operational 
data, reliability data, and maintenance data. The model was 

written in GPSS-II and ran on an IBM 360 computer. 

The original Synder model was expanded to include multiple 
launch windows and the operational sequence when a launch window 
was missed and the spacecraft had to be recycled to the next 
launch window (Schroer 1969). The model was used to predict the 
probability of launching a spacecraft within a given set of back- 
to-back launch windows. A second objective was to predict the 
probability of launching in a subsequent window, given a window 
had been missed and a recycle sequence and a possible hold had to 
be executed before resuming the countdown. 

The expanded model included two countdown sequences. The 

first sequence was the main countdown sequence identical to the 
Synder model. The second sequence was the recycle sequence that 
consisted of a number of backout sequences containing those 
events that were required to return the countdown to some 
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preceding point. The recycle sequence also consisted of a 
recycle hold containing those activities that were required to 
sustain the vehicle status at a particular time in the countdown. 
The model was written in GPSS-II, contained 2300 blocks, several 
Fortran help routines and ran on the IBM 360 computer. 

A goal of the ANPS system is to be able to model these types 
of applications more quickly and accurately than previously done 
using conventional simulation techniques. 

ANPS SYSTEM 

Figure 1 gives an overview of the ANPS system. The ANPS 
system is designed using the elements of automatic programming as 
its foundation. The three AP elements in ANPS are; an interac- 
tive user dialogue interface, a library of software modules, and 
an automatic simulation code generator. In Figure 1, the tradi- 
tional programming task of flow charting has been replaced by the 
interactive user dialogue interface and the problem specifica- 
tion. Likewise, the program writing task in Figure 1 has been 
replaced by the automatic code generator and the library of soft- 
ware macros. The ANPS system is written in Turbo Prolog (Borland 
1986) on an IBM PC class of personal computer. The system con- 
tains 1218 lines of code and 86 subroutines. The simulation code 
generated by ANPS is GPSS/PC (Minuteman 1986). 



Figure i. ANPS system overview 
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Interactive User Dialogue Interface 


There are three commonly used AP user interfaces. These are 
a natural language interface, a graphical user interface, and an 
interactive dialogue interface. Several natural language inter- 
face developments are Heidorn (1974) and Ford and Schroer (1987). 
An example of a graphical interface development is Khoshnevis and 
Chen (1986). Several interactive dialogue interfaces are Haddock 
and Davis (1985), Brazier and Shannon (1987), and Murray and 
Sheppard ( 1988) . 

The AN PS system uses an interactive dialogue interface. 
This interface is probably the most common and easiest to develop 
interface. Using this interface, the user, or modeler, enters 
into a dialogue with the ANPS system to define the problem speci- 
fication, or model . 

Library of Software Modules 

The robustness of an AP system is dependent on the diversity 
and completeness of its library of software modules. 
Furthermore, this library is generally domain specific. When new 
modules or subroutines are needed, expert simulation programmers 
are needed to write the simulation code and to assure the proper 
i nterf ace . 

Since the ANPS system is domain specific to system reliabi- 
lity networks, the number of needed software modules is minimal. 
At this point of development, ANPS consists of the following four 
modules: 

° Fixed activity operation function 

° Variable activity operation function 

° Activity failure function 

0 Activity interrupt function 

These modules were selected based on a detailed evaluation 
of the two previously discussed models by Synder (1967) and 
Schroer (1969). I nteresti ngly , several of these previously deve- 
loped modules were written as Fortran HELP routines using the old 
GPSS-II . 

The fixed activity operation function (VENT_A) simulates the 
operation of each fixed time activity and its time to failure. 
If the activity fails during its operation, the transaction is 
forwarded to the activity failure function (FAIL). 

The variable activity operation function (VENT_B) simulates 
the operation of each variable time activity and its time to 
failure. This activity is not completed until all other related 
activities are completed. For example, system power is a 



variable time function that will be on until all activities 
requiring power are completed. If the activity fails, the tran- 
saction is forwarded to the activity failure function (FAIL). 

The activity failure function (FAIL) simulates the failure 
of an activity as indicated by functions VENT_A and VENT_B. When 
an activity fails, all the dependent activities enter a hold 
state. The function then simu-lates the time to repair the acti- 
vity. If another activity fails during the delay of a dependent 
activity and the dependent activity is dependent on the first 

failed activity, the additional time to repair, if any, is added 
to the delay of the dependent activity. The function assumes 
that a dependent activity that has been delayed cannot fail 

during the delay. The activity interrupt function XACT_DELAY 
contains the logic to add any additional time to an activity on 
hold if another activity fails during the hold and the held acti- 
vity is dependent on the failed activity. 

Figure 2 is a listing of the GPSS code for the fixed acti- 
vity function VENT_A. Note that the subroutine makes extensive 
use of indirect addressing. The system also contains a large 
number of matrix savevalues for transferring data between the 

subroutines and the main program. Initially, all the input data 
from the problem specification are entered into these matrix 

saveval ues . 


Automatic Simulation Code Generator 


The output from the interactive dialogue interface, or the 
problem specification, is then used as input to the code genera- 
tor program which automatically writes the program code in the 
target simulation language GPSS. The system creates the mai-n 
program that includes the appropriate calls to the selected 
library macros. 


1 .360 
1 370 

* 

* 

ACT I V I TV 

TIME SIMULATION GENERATOR 

1 380 
1 390 

* 

VENT _ A 

SEIZE 

P2 

.1 400 


ASSIGN 

ET I ME , MX $WORI< _T I ME < P3 , 

1 4 1 0 

BACK3 

ASSIGN 

M T T F , M X $ F _ T I M E <P3, 1 ) 

1 420 


TEST L 

P*MTTF ,, P $ E T I ME , NOFA I L 

1 430 


ADVANCE 

P*MTTF 

1 440 


ASSIGN 

ROW , P3 

1 430 


TRANSFER 

SBR , FA I L , RTRN 1 

1 460 


ASSIGN 

REST _T I ME , V*T 1 ME3 

1 470 

TIME 3 

F VARIABLE 

P$ET I ME-P*MTTF 

1 480 


ASSIGN 

ETIME, PUREST _T I ME 

1 490 


TRANSFER- 

, BACK 3 

.1 500 

N OF AIL 

ADVANCE 

PUET I ME 

1510 


RELEASE 

F'2 

1 520 


TRANSFER 

F', RTRN 2, 1 


Figure 2. GPSS listing for function VENT_A 
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Table I gives the time parameters for the activities. These 
parameters include activity duration, time to failure and time to 
repair. Activities ACT1 and ACT2 have variable times; therefore, 
the activities will operate during the entire duration of the 
system. Table II gives the operational dependencies between the 
activities. For example, a failure of activity ACT1 will cause a 
stopping of activities ACT3, ACT4, and ACT5. Likewise, a failure 
of activity ACT9 will also stop activity ACT5. 


Table I. Activity Time Parameters 


Activity 

Duration 

Time to Failure 

Time to Repair 

ACT1 

Variable 

E ( 200 ) 

N( 20,4) 

ACT2 

Variable 

E ( 200 ) 

N( 20,4) 

ACT3 

100 

E ( 120 ) 

N( 10,2) 

ACT4 

40 

E ( 60 ) 

N(5,l) 

ACT5 

60 

E ( 80 ) 

N(5,l) 

ACT 6 

50 

E ( 60 ) 

N(5,l) 

ACT 7 

30 

E(100) 

N( 10,2) 

ACT8 

60 

E(100) 

N( 10,2) 

ACT9 

60 

E ( 50 ) 

N(5,l) 

ACTIO 

40 

E ( 60 ) 

N(5,l) 

ACT11 

80 

E(100) 

N( 10,2) 

ACT12 

Dummy 

0 

0 


Table II. Operational Dependencies Between Activities 



Dependent Activities 

Activity 

"ACTI ACT2 Pm ACT? ACT 5 ACT6 ACT 7 ACT8 ACT9 ACTIS ACTTI ACTl2 

ACT1 

X XXX 

ACT2 

X XX 

ACT 3 

X X 

ACT4 

X 

ACT 5 

X 

ACT 6 

X 

ACT 7 

X 

ACT8 

X 

ACT9 

X X 

ACTIO 

X 

ACT11 

X 

ACT 12 

X 
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Figure 5 is a partial listing 
gue for defining activity ACT3. A 
at node 3. The activity type is f - 
time to failure follows an exponen 
of 120, the time to repair the 
distribution with a mean of 10 an 
Activity ACT6 is dependent on ACT3. 


Figure 6 is a partial 
Note that the code consists 
ASSEMBLE blocks that define 
route the transactions to the 
vity operation subroutines. 


of a 
the 


Name for GPSS Program : 

EX AMP. 1 

1. Number of activities : 

12 

2. Activity attributes: 


Activity name^ 

*ACT3 

Activity type (f i >:ed/ var i abl e) 

FIXED 

Duration distribution type 

CONSTANT 

mean time 

100 

Starting node number 

1 

Ending node number 


MTTF distribution type 

EXPONENTIAL 

mean time 

120 

MTTR distribution type 

NORMAL 

mean time 

10 

standard deviation 

2 

Number of dependent activities 

: 1 

t 

Name of dependent activity 1:$ACT6 

j 

] 


Figwv 5. Partial listing of interactive user dialogue 


of the interactive 

user dialo- 

CT 3 

starts at node 

1 and ends 

xed , 

the 

dur at i on 

is 100, the 

t i a 1 

distribution 

with a mean 

acti vi ty 

f o 1 1 ows 

the normal 

d a 

standard deviation of 2. 

g of the 

GPSS main program. 

number of 

SPLIT, TRANSFER and 

etwor k . 

The TRANSFER blocks 

priate fixed or variable acti- 

1945 


GENERATE 


1 950 

MORE 

SPLIT 

1 , MM 

1955 


GATE LS 

SW I TCH_MORE 

1960 


LOGIC R 

SWITCH_MQRE 

1965 


TRANSFER 

, MORE 

1970 

MM 

MARK 

SYSTIME 

2000 

EV1 

ADVANCE 


2001 


TRANSFER 


2002 

EV2 

ASSEMBLE 

2 

2003 


TRANSFER 

,A4 

2004 

EV3 

ASSEMBLE 

2 

2005 


TRANSFER 

,A5 

2006 

EV4 

ASSEMBLE 

2 

2007 


LOGIC S 

SWITCH_END 1 

2008 

EEV4 

ASSEMBLE 

2 

2009 


TRANSFER 

, A12 

2010 

EV5 

ASSEMBLE 

1 

2011 


LOGIC S 

SWITCH_END2 

2012 

EEV5 

ASSEMBLE 

2 

2013 


TRANSFER 

, END1 

2014 

EV6 

ADVANCE 


2015 


TRANSFER 

,A7 

2016 

EV7 

ADVANCE 


2017 


TRANSFER 

,A9 

2018 

EV8 

ADVANCE 


2019 


TRANSFER 

, All 

2020 

A1 

ASSIGN 

2,*ACT1 

2021 


SPLIT 

1 , A2 

2022 


ASSIGN 

3,1 

2024 


LOGIC R 

SWITCH_END1 

2023 


TRANSFER 

SBR, VENT_B, RTRN2 

2026 


TRANSFER 

, EEV4 

2027 

A2 

acc T r*i* 1 

7.SACT2 

2<v? 0 






TRANSFER- 

, ^ 

2082 

A10 

ASSIGN 

2,*ACT10 

2083 


ASSIGN 

3, 10 

2085 


TRANSFER 

SBR, VENT_A,RTRN2 

2086 


TRANSFER 

, EV8 

2088 

A 1 1 

ASSIGN 

2, *ACT 1 1 

2089 


ASSIGN 

3, 11 

2091 


TRANSFER 

SBR, VENT_A, RTRN2 

2092 


TRANSFER 

, EV4 

2094 

END1 

TABULATE 

SYSTIME 

2095 

SYSTIME TABLE 

MF"$SYST I ME , 0 , 50 , 

2096 


LOGIC S 

SWITCH.MORE 

2097 


TERMINATE 

1 


Figure 6. Partial GPSS listing of main pr 
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CONCLUSIONS 


The ANPS system is currently in limited operation on an IBM 
PC microcomputer. A number of relatively small network problems 
have been solved using the system. Given the success in modeling 
these small networks, it appears that the ANPS system can readily 
model the two large Saturn V prelaunch models by Synder (1967) 
and Schroer ( 1969 ). Based on this initial testing and eva- 
luation, the following comments can be made: 

° The interactive user dialogue provides for a formal and 
structured procedure for acquiring information on the 
network being modeled. 

° The interactive user dialogue expedites the definition of 
the problem specification and assures a complete and 
detailed definition of the problem specification. 

0 The automatic code generator results in structured simu- 
lation code that is easy to read, trace and modify. 

0 The overall clarity of the simulation code is greatly 
improved . 

0 The ANPS system is ideal for rapid prototyping and can 
produce simulation code that is syntax error free. 

° The ANPS system reduces the knowledge level required by 
the modeler of the simulation language. 

The ANPS system also has several disadvantages. These 
disadvantages include: 

° The system is domain specific and limited by the robust- 
ness of its library of macros. 

° The GPSS code generated by ANPS probably is longer, and 
consequently requires more memory and takes longer to 
execute, than a nonstr uctured equivalent program. 

A second version of ANPS is currently under development on 
an Apple Mac II using HyperCard. This version uses an interac- 
tive graphical interface rather than the interactive user dialo- 
gue. With this version it will be possible to compare the 
different interface approaches to defining the problem specifica- 
tion, the use of Turbo Prolog versus HyperCard, and the PC and 
Mac II platforms. 
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